This Page Is Inserted by IFW Operations 
and is not a part of the Official Record 

BEST AVAILABLE IMAGES 

Defective images within this document are accurate representations of 
the original documents submitted by the applicant. 

Defects in the images may include (but are not limited to): 

• BLACK BORDERS 

• TEXT CUT OFF AT TOP, BOTTOM OR SIDES 

• FADED TEXT 

• ILLEGIBLE TEXT 

• SKEWED/SLANTED IMAGES 

• COLORED PHOTOS 

• BLACK OR VERY BLACK AND WHITE DARK PHOTOS 

• GRAY SCALE DOCUMENTS 



IMAGES ARE BEST AVAILABLE COPY. 



As rescanning documents will not correct images, 
please do not report the images to the 
Image Problem Mailbox. 




Fig. 5-21. Reverse path forwarding. 

packet and a priori knowledge of the subnet diameter, or a list of packets aJready 
seen per source). 



5.3. CONGESTION CONTROL ALGORITHMS ' 

In this section ve will examine five strategies for controlling congestion. These 
strategies involve allocating resources in advance, allowing packets to be discarded 
when they cannot be processed, restricting the number of packets in the subnet, 
using flow control to avoid congestion, and choking off input when the subnet is' 
overloaded. 

5 3.1. Preallocation of Buffers 

If virtual circuits are used inside the subnet, it is possible to solve the conges- 
tion problem altogether, as follows. When a virtual circuit is set up, the call request 
packet wends its way through the subnet, making table entries as it goes. When, it 
has arrived at the destination, the route to be followed by all subsequent data traffic 
has been determined and entries made in the routing tables of all the intermediate 
IMPs. 

Normally, the call request packet does not reserve any buffer space in the inter- 
mediate IMPs, just table slots. However, a simple modification to the setup algo- 
rithm could have each call request packet reserve one or more data buffers as well. 
If a call request packet arrives at an IMP and all the buffers are already reserved, 
either another route must be found or a "busy signal" must be returned to the 
caller. Even if buffers are not reserved, some aspiring virtual circuits may have to 
be rerouted or rejected for lack of table space, so reserving buffers does not add any 
new problems that were not already there. 

By permanently allocating buffers to each virtual circuit in each IMP, there will 
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" ; vays be :\ rJace to st<^-:- :*my incoming packer until it can be forwarded. First con C 
-icier the case of a stop-and-wait IMP- IMP protocol. One buffer per virtual circuit - 
p^r IMP is sufficient for simplex circuits, and one for each direction is sufficient f 0r ^* 
full-duplex circuits. When a packet arrives, the acknowledgement is- not sent back" : * 
to the sending IMP until the packet has been forwarded. In effect, an acknowledge';^ 
ment means that the receiver not only received the packet correctly, but also that it 
has a free buffer and is willing to accept another one. If the IMP -IMP protocol* ^2 
allows multiple outstanding packets, each IMP will have to dedicate a full ^ 
window's worth of buffers to each virtual circuit to completely eliminate the possi- : ?t* 
blliry of congestion. 

When each virtual circuit passing through each IMP has a sufficient amount of"?- 
buffer space dedicated to it, packet switching becomes quite similar to circuit ^ 
switching. In both cases an involved setup procedure is required. In both -cases'*"'"" 
substantial resources are permanently allocated to specific connections, whether or v 
not there is any traffic. In both cases congestion is impossible because all the ' t 
resources needed to process the traffic have already been reserved. And in boihCT:' 
cases there is a potentially inefficient use of resources, because resources not being 71 
used by the connection to which they are allocated are 'nevertheless unavailable to > 
anyone else. " £ 

Because dedicating a complete set of buffers to an idle virtual circuit is expen- ; 'f 
sive, some subnets may use it only where low delay and high bandwidth are essen- r --7 
tiaJ, for example on virtual circuits carrying digitized speech. For virtual circuits 
where low delay is not absolutely essential all the time, a reasonable strategy is to \% 
associate a timer with each buffer: If the buffer lays idle for too long, it is released, '1 
to be reacquired when the next packet arrives. Of course, acquiring a buffer might re- 
take a while, so packets will have to be forwarded without dedicated buffers until "3 
the chain of buffers can be set up again. . : $ 

"** !• -j 

5-3.2. Packet Discarding 

Our second congestion control mechanism is just the opposite of the first ontCH 
Instead of reserving all the buffers in advance, nothing is reserved in advance. If a "J 
packet arrives and there is no place to put it, the IMP simply discards it. If the sub-*-^ 
net offers datagram service to the hosts, that is all there is to it: congestion is -f 
-resolved by discarding packets at will. If the subnet offers virtual circuit service, a 
copy of the packet must be kept somewhere so that it can be retransmitted later. [* 
One possibility is for the IMP sending the discarded packet to keep timing out and -jf 
retransmitting the packet until it is received. Another possibility is for the sending { 
IMP to give up after a certain number of tries, and require the source IMP to time :| 
out and start all over again. ;a[ 

Discarding packets at will can be carried too far. It is clearly stupid in the 4 
extreme to ignore an incoming packet containing an acknowledgement from a 
neighboring IMP. That acknowledgement would allow the IMP to abandon a by- ;J 
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now-received packet and thus free up a buffer. However, if the IMP has no spare 
cuiV-ts. it cannot acquire any more incoming packets to see if they contain acknow- 
ledgements. The solution is to permanently reserve one buffer per input line to 
allow all incoming packets to be inspected. It is quite legitimate for an IMP to 
examine a newly arrived packet, make use of any piggybacked acknowledgement, 
and then discard the packet anyway. Alternatively, the bearer of good tidings could 
be. rewarded by keeping it, using the just freed buffer as the new input buffer. 

If congestion is to be avoided by discarding packets, a rule is needed to tell 
when to keep a packet and when to discard it. Irland (1978) studied this problem 
and came up with a simple, yet effective heuristic for discarding packets. In the 
absence of any explicit rule to the contrary, a single output line might hog all the 
available buffers in an IMP, since they are simply assigned first come, first served. 
Figure 5-22(a) shows an IMP with a total of 10 buffers. Three of these are per- 
manently assigned to the input lines. The remaining seven are holding packets 
queued for transmission on one of the output lines. 
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Fig. 5-22. Congestion can be reduced by putting an upper bound on the number of 
buffers queued on an output line. 

Even though two output lines are idle, any incoming packets destined for these 
lines must be discarded because there are no spare buffers. This is obviously 
wasteful. Irland's idea is to limit the number of buffers that may be attached to any 
one output queue. For example, if the limit were set at four,, the situation of Fig. 5- 
22(b) would prevail: three unassigned buffers. A newly arrived packet wanting to 
go out on the first output line would be discarded rather than allowing it to increase 
the queue length to five. 

This strategy is not really as drastic as it may appear. After all, that output line 
is already running at maximum capacity. Having seven packets queued instead of 
four will not pump the bits out any faster, but it will allow traffic for the other lines 
to be forwarded immediately, possibly doubling or tripling the output rate of the 
IMP. In any case, the discarded packet will be retransmitted shortly. If the system 
is well tuned, it will even be retransmitted before the queue empties, so its initial 
rejection will not even be noticed. 

Irland studied several different algorithms for determining maximum queue 
length, m, for an IMP with k buffers (buffers permanendy dedicated for input do 
not count). The -uncontrolled case is m - k. If there are s output , lines, the case 
m =k/s effectively means that each buffer is dedicated to a given output line. No 
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,nay borrow even one buffer from an idle line, ever. Intuitively (his is n 
efficient, and the study bears this out. ' s not 

It turns out that the optima] value of m is a complicated function of rh. 
traffic. Although the IMP could attempt to measure stS^? 
adjust m, if the traffic were bursty, this probably would not wor wc ' » 

^o^c™ IWT Pl F ni,e ° f th rV hat USUaJ,y giv « b«no"^J. 
^ buffe^ou^^d.^ ^ P ° 01 bUffCrS ^ 

A related idea, due to Kamoun (1976). directly prevents any line or lines from 
starving: a minimum number of buffers is dedicated to each line If there k 

Kloun r h £ T y bUff£rS * r£SerVed - Wand ' S meth0d be con td wuh 

TnTS^ef miTrnTod. ^ 3 ^ ° f ^ ** ^ ^ : 

Although discarding packets is easy, it has some disadvantages. Chief amona " 

^ 5andWidth needed f ° r the ^"cates. ^ the probability of a «ck« 

bemg discarded is p, the expected number of transmissions before is" accepted 

hol~H , , ^ 1S h ° W long Ac timeout ^ould be. If it too 

short, duplicates will be generated when they are not needed, making the conges " 
tion worse. If u , s too long, the delay will suffer conges- 

1° minimi2e th£ a 171011 " 1 of bandwidth wasted on the retransmission of 
discarded packets is to systematically discard packets that have not yet trTve ed far 
and hence do not represent a large investment in resources. The hmiW ca Se of 
this strategy is to discard newly arrived packets from hosts in preference^ discard " 
mg transit traffic. For example, IMPs could refuse or discard new packets fret 
attached hosts whenever the number of buffers tied up by new pXs or Z 
packets) exceeds some threshold. v K ;; 



5.3.3. Isarithmic Congestion Control 
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Congestion occurs when there are too many packets in the subnet A direct 

a91»™i:^ n ™l I, 1 I tD Y lt Xhe nUmbCr ° f > aCke * * * subnet. Dav e 
( 1 972) proposed a method that enforces precisely such a limit 

I ? eLh ° d ' CallCd isarithmic il keeps the number of packets con- 

^ wtL e to X s e nd Pe a rm,t , S ' WHiCh CilCUlate ab ° Ut ^ SUbnet - Whenever^, " 

ZufrT Si P " JUSt glVCn t0 U by its host < ir mus t nxst capture a permit •= 

and destroy i, When the destination IMP finally removes the packet from th^sT : 
net it regenerates the permit. These simple niles ensure that the number of packet 

in the subnet will never exceed the number of permits initially present P 2 

However, this method has some problems. First, although it does guarantee that ? 

the .ubnet as a whole will never become congested, it does not guaVa^e^Ta " 

given IMP will not suddenly be swamped with packets S ua ™itee that a , 

Second, how to distribute the permits is far from obvious. To prevent a newlv 

generated packet from, suffering a long delay whUe the local IMP tries to scout up a ; 
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permit, the permits must be uniformly distributed, so that every IMP has some. On 
iht other hand, to permit high-bandwidth file transfer, it is undesirable for the send- 
ing IMP to have to go hunting all over the place to find enough permits. It would 
be nicer if they were all centralized, so that requests for substantial numbers could 
be honored quickly. Some compromise must be found, such as having a maximum 
number of permits that may be present at any IMP, with excess permits required to 
hunt for an IMP with space. Note that the random walk of the excess permits itself 
puts a load on the subnet. 

Third and by no means least, if permits ever get destroyed for any reason, (e.g., 
transmission errors, malfunctioning IMPs, being discarded by a congested IMP), 
the carrying capacity of the network will be forever reduced. There is no easy way 
to find out how many permits still exist while the network is running. 

5.3,4. Flow Control 

Some networks (notably the ARPANET) have attempted to use flow control 
mechanisms to eliminate congestion. Although flow control schemes can be used 
by the transport layer to keep one host from saturating another, and flow control 
schemes can be used to prevent one IMP from saturating its neighbors, it is difficult 
to control the total amount of traffic in the network using end-to-end flow control 
ruies.. Still, if the hosts are forced to stop transmitting due to strict flow control 
rules, the subnet will not be as heavily loaded. 

Flow control cannot really solve congestion problems for a good reason: com- 
puter traffic is bursty. Most of the time an interactive user sits at his terminal, 
scratching his head, but once in a while he may want to scan a large file. The 
potential peak traffic is vastly higher than the mean rate. Any flow control scheme 
which is adjusted so as to restrict each user to the mean rate will provide bad ser- 
vice when the user wants a burst of traffic. On the other hand, if the flow control 
limit is set high enough to permit the peak traffic to get through, it has little value as 
congestion control when several users demand the peak at once. . (If half the people 
in the world suddenly picked up their telephones to call the other half, there would 
be a lot of busy signals; the telephone system is also designed for average traffic, 
not worst case.) 

When flow control is used in an attempt to quench congestion, it can apply to 
the traffic between pairs of: 

1. User processes (e.g., one outstanding message per virtual circuit). 

2. Hosts, irrespective of the number of virtual circuits open. 

3. Source and destination IMPs, without regard to hosts. 

In addition, the number of virtual circuits open can be restricted. 
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Choke t:\c.\As . ^ 

Although limiting the volume of traffic between each pair of IMPs or host, m 
indirectly alleviate congestion it does so at the price of potentially redact 
throughput even when there is no threat of congestion. What is really needed k g * 
mechanism that is triggered only when the system is congested 5 a .; 

One way is to have *ach IMP monitor the percent utilization of each of its out" * 
put lines. Associated with each line is a real variable, u, whose value, between 0 0 * 
and 1.0 reflects the recent utilization of that line. To maintain a good estimate o u ^ 
a sample of the instantaneous line utilization, /(either 0 or 1), can be made period"" -2 
^ally and u updated according to *^ 001 

.i'.'.. 
, • 

"new =^" 0 |d +(1 -a)/ 



where the constant a determines how fast the IMP forgets recent history 

Whenever u moves above the threshold, the output line enters a'" warning" C 
state, Each newly amvmg packet is checked to see if its output line is in warniL " 
state. If so the IMP sends a choke packet back to the source host, giving it me ' 
destmauon found in the packet. The packet itself is tagged, (a header bit is turned * 
the usual way ^""^ ™? ^ choke P ack ^ s later « and is forwarded in * 

When the source host gets the choke packet, it is required to reduce the traffic * 
sent to the specified destination by X percent. Since o'ther packets a^d at the 4i 

packe s, the host should .gnore choke packets referring to that destination for a A 

fixed time interval. After that period has expired, the host listens for more choke & 

packets for pother interval. If one arrives, the line is still congested, so the host ^ 

reduces the flow still more and begins ignoring choke packets again. If no choke - 

packets arrive during the listening period, the host may increase the flow again iB 

The feedback implicit in this protocol should prevent congestion, yet not throttle 1 

any flow unless trouble occurs. • tnrorae ^ 

For on V e er l mp i0nS m * is COn S estion algorithm have been proposed -3 

For one, the IMPs could maintain two critical levels. Above the first level choke -1 
packets are sent back. Above the second, incoming traffic is just discarded the ~| 

fnl , V u l f ° r lhC ^ C ° ^ Which hosts have wa ™d recendy 3 
about which destinations, and which hosts have not. 3 

Another variation is to use queue lengths instead of line utilization as the trigger 

signal. The same exponential weighting can be used with this metric as with u°of 

HnnT.' . P ° Ssib r Uit y is to have the °*Ps propagate congestion informa- 

jon along with routing information, so that the trigger is not based on only one 
IMPs observations, but on the fact that somewhere along the path there is a 
bottleneck. By propagating congestion information around the subnet, choke 
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packets can be sent earlier, before too many more oackets arP „nru 
preventing congestion from building up. P U " der Way ' thus 

5.3.6. Deadlocks 

The ultimate congestion is a deadlock, also called a lockun Th, fire, ta™ 
not proceed until the second IMP rW, \ u J °<*up. The first IMP can- 

proceed because it Ts wait* £1^^ T ^ SeCOnd ^ Cannot 

waiting ror the first IMP to do something p^k t\xt> L 

ground to a complete halt aj,d wUl st a y that way fa-™ S t haVe 
sidered a desirable propeny to have in your neZrk d '° CkS 316 " 0t COn " 

involved in the lockup effectively blocked, deluding those not 
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Fig. 5-23. Store-and-fonvard lockup, (a) Direct, (b) Indirect 



store^fo^t^r'ln 0 * 80 ' T' '"T^ 3 ; °"" i0n '° *= P robl - »f 
buffers beLg u^ nodes of tne ™* a"' ' dlreC ' ed .^P h * constructed, with the 

or adjacent IMPs t£ „, t ? P " H 0 ™"' piUrs of buffers ! " 'he same IMP 
■ aojacent UVU's. The graph is constructed n such a w av that If »ll „„.!. . 

from buffer to buffer along the arcs of me graph, then no dead^eks c£ £u, ^ 
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.: a simple example of their method, consider a subnet with N LMPs in which 
tlu- io.igest route from any source to any destination is of length M hops. Each IMP 
r. :cds M + 1 buffers, numbered from 0 to M. The buffer graph is now constructed 
by drawing an arc from buffer /' in each node to buffer / + 1 in each of the adjacent 
nodes. The legal routes from buffer / at IMP A axe those to a buffer labeled /' + 1 at 
IMPs adjacent to A, and then to a buffer labeled / + 2 at IMPs two hops from A, etc. 

A packet from a host can only be admitted to the subnet jf buffer 0 at the source 
IMP is empty. Once admitted, this packet can only move to a buffer labeled 1 in an 
adjacent IMP, and so on, until either it reaches its destination and is removed from 
the subnet, or it reaches a buffer labeled M, in which case it is discarded. (If M j s 
chosen longer than the longest route, then only looping packets will be discarded.) 
A packet in buffer i in some IMP may only be moved if buffer / + 1 in the IMP 
chosen by the routing algorithm is free. Note that numbering the buffers does not 
restrict the choice of routing algorithm, which can be static or dynamic. 

To see that this algorithm is deadlock free, consider, the state of all buffers 
labeled M at some instant. Each buffer is in one of three states: empty, holding a 
packet destined for a local host, or holding a packet for a distant host. In the second 
case the packet can be delivered, in the third case the packet is looping and must be 
dropped. In all three cases the buffer can be made free. Consequently, all the pack- 
ets in buffers labeled M - 1 can now be moved forward, one at a time, to be 
delivered or discarded. Once all the buffers labeled M - 1 are free, the packets in 
buffers labeled M - 2 can be moved forward and delivered or discarded. Eventu- 
ally, all packets can be delivered or discarded. If the routing algorithm guarantees 
that packets cannot, loop, then M can be set to the longest path length, and all pack- 
ets will be correctly delivered with no discards and no deadlocks. 

Merlin and Schweitzer have also presented many improvements to this simple 
strategy to reduce the number of buffers needed and to improve the performance. 
For example, a packet that has already made / hops (i.e., is currently in a buffer 
labeled 0. can be put in any available higher numbered buffer at the next hop, not 
just in buffer / + 1 . As long as the sequence of buffer numbers is monotonically 
increasing, there can be no deadlocks. 

Although this algorithm avoids deadlock completely, it has the disadvantage 
that under normal circumstances many buffers will be wasted due to lack of the 
appropriate packets. Furthermore, lines will be frequently idle because the buffer 
that the packet at the head of the queue happens to. need is not available at the 
moment. 

A completely different deadlock prevention algorithm that does not have these 
properties has been published by Blazewicz et.al. (1987a). In their algorithm, each 
packet bears a globally unique timestamp. This stamp contains the time the packet 
was created in the high-order bits and the machine number in the low-order bits. It 
is not essential that all the clocks be synchronized, aJthough the algorithm tends to 
give, fairer service if the clocks are not too far apart. 

The algorithm requires each IMP to reserve one "buffer per input line as a 
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special receive buffer. All the other buffers can be used for holding packets in tran- 
sit. These packets axe queued in timestamp order in a separate queue for each out- 
put line, as illustrated in Fig. 5-24. In the absence of any deadlock prevention algo- 
rithm, the three IMPs in Fig. 5-24 would be deadlocked because although each one 
can receive a packet from its neighbors, it has nowhere to store it while, the packet 
waits its rum for the next hop.. 



Find oldest packet 



Winner Loser 



One of these 
will have to 
be exchanged 
with 12 




A b • c 

Fig. 5-24. Three potentially deadlocked IMPs. "J' 
The essence of the algorithm is that it makes a distinction between three condi- 
tions. In all three cases we assume that A has an important packet that it wants- to 
send to B. The conditions are: 

1 . B has a free buffer. 

2. B does not have a free buffer, but it does have a packet- for A. " 

3. B has neither a free buffer nor a packet for A. 

In case 1, A just sends its packet. In case 2, A and B exchange packets, so that the 
newly arrived packet can be put in the buffer just freed by the packet going the 
other way. In case 3. B is forced to choose a packet not destined for A (preferably, 
one that is at least going in the same general direction as A) and this packet -'ii 
exchanged with /4as in case 2. 

Now we can explain the algorithm and prove that it is deadlock free. Whenever 
a line goes idle, the two IMPs at the ends of it exchange control packets giving the 
timestamp of its oldest packet that wants to use the line. The one with the lowest 
number (oldest packet) wins and that packet is sent, even if case 3 applies and the 
losing IMP is forced to send another packet in the wrong direction to free up buffer 
space for the winner. At any instant, one packet in the subnet has the honor of 
being the oldest. This packet will always come on top in any IMP-IMP'discussion 
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out age, -o this pickc will make nonstop progress to its destination. As soon as 
U has been delivered, some other packet becomes the oldest, and it can then 
f.rocced unobstructed to its destination. As time marches on, every packet eventu- 
ally becomes the oldest and is delivered. 

Two criticisms can be leveled at this algorithm. First, a young packet may be 
sent far out of its way before it acquires enough seniority to start consistently wi_n- 
ni.\g the IMP-IMP timestamp comparisons. However, in practice, case 3 only 
c-curs when the subnet is heavily loaded (all buffers full). If an IMP has, say, 3 or 
4 outgoing lines and 20 to 50 full buffers, chances are that none of the' outgoing 
queues will be empty, so that the losing IMP will nearly 'always be able to find a 
good packet to exchange with the winner. 

The second criticism has to do with clock synchronization. If one IMP's clock 
is a few seconds ahead of all the others, its packets will be at a competitive disad- 
vantage when timestamps are compared. Still, within a few seconds, its packets 
will get delivered, so the condition is annoying but not fatal. If each pair of adja- 
cent LMPs periodically exchanges clock values, each IMP can then set its time to 
the average of its neighbor's times. In this way, no clock can get very far out of 
step with the rest. 

Store -and- forward lockups are not the only kind of deadlocks that plague the 
subnet. Consider the situation of an IMP with 20 buffers and lines to four other 
IMPs. as shown in Fig. 5-25. Four of the buffers are dedicated to. the four input 
lines, to help alleviate congestion. Assume that a sliding window protocol is being 
used, with window size seven. Further, assume that packets are accepted out of 
order by the IMP, but must be delivered to the host in order. At the time of the 
snapshot, four virtual circuits, 0, 1.2, and 3. are open between the host and other 
hosts. 

Rather than dedicate a full window load of buffers to each open virtual circuit, 
buffers are simply assigned on a first come, first served basis. As soon as the next 
sequence number expected by the host becomes available, that 'packet is passed to 
the host (with each virtual circuit independent of all the others). However higher 
number packets within the window are buffered in the usual way. 

In Fig. 5-25 v and s indicate the virtual circuit and sequence number of each 
packet, respectively. The host is waiting for sequence number 0 on all four virtual 
circuits, but none of them have arrived undamaged yet. Nevertheless, all the 
buffers are occupied. 

If packet 0 should arrive, it would have to be discarded due to lack of buffer 
space. As a result, no more packets can be passed to the host and no buffers freed. 
This deadlock occurred in the ARPANET in a slightly different form, and was 
called reassembly lockup. 

. In the ARPANET there are multipacket messages (i.e.. messages too large to fit 
into a single packet). By allowing hosts to pass relatively large chunks of informa- 
tion to the LMPs in a single transfer, the number of host interrupts could be reduced. 
The sending IMP splits multipacket messages into individual packets and sends 
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Fig. 5-25. Reassembly lockup. 

each one separately. The destination IMP must put all the pieces together before 
passing.the reassembled message to the host. If pieces of several multipacket mes- 
sages have managed to commandeer all the available buffer space in the destination 

deadlockedl 1SSinS ^" ^ * thC IMP (and host > wUl **' 

The ARPANET solution is to have the source IMP ask the destination IMP per- 
mission to send a multipacket message. The destination IMP then dedicates enough 
buffers to reassemble the full message before telling the source to go ahead The 
sliding wuidow version of the deadlock caii only be prevented by dedicating a full 
window s worth of buffers to each open virtual circuit. The reason this strategy is 
more attractive in the ARPANET case is that there most (96%) messages are single 
packet, not multipacket, whereas in the sliding window case, in effect all messages 
are multipacket/ 5 

" Two other problems discovered in the ARPANET are worth mentioning here 
Both were caused by malfunctioning IMPs. All of a sudden, one IMP announced 
that it had zero delay to aJl other IMPs in the entire subnet. The adaptive routing 
algorithm spread the good news far and wide. The other IMPs were ecstatic 
Wuhin a few seconds, practically all of the traffic in the entire subnet was headed 
toward the only IMP that was not working properly. Although not a deadlock, this 
certainly brought the whole network to a grinding halt. 

The other problem was also caused by a failing memory. One fine day the 
Aberdeen IMP (on the East Coast) decided that it was the UCLA IMP (on the West 
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Coast) The ccnscquenccs of this case of mistaken identity can be easily imagined 
especially for the UCLA and Aberdeen hosts. B in ec^. ; . 

The fix applied to the IMP software was to have each IMP periodically com™,, 
a software checksum of its own code and tables, in hope of discovering fail" 
memory words, such as those that caused the above problems. Nevertheless thl 
nagging question of how you prevent one bad IMP from bringing the whole ne, 
work down remains. One of the arguments in favor of computer networking is Z't 
higher reliability can be achieved so: if one machine goes down, there are UU 
plenty of others around. However, if a single failure at one site often pollutes the 
enure nanonwide (or worldwide) system, there may be no' advantage at all 

An exhaustive catalog of other network deadlocks and possible solutions to 
them is given by • La, (1982). Other deadlock prevention methods are discussed by 
Blazewicz etal. (1987b), and Gopal (1985). ° 0y . 

5.4. INTERNETWORKING 

Up until now we have implicitly assumed that there is a single homogeneous 
network, with each machine using the same protocol in each layer Unfortunately 

20 S 0^ S ^f On 15 r Udly 0ptimi?tiC - Many different network * More thari 

FjSS? f ne T 0r , kS ' m ° re lhan 2000 DECNET ne ^orks, and uncountably many 
^ v^T ^ ™aginable ^ ™ da «y option all over the world (Green 
1986). Very few of these use the OSI model. In this section we will take a carefu 
look at the issues that arise when it becomes necessary to interconnect two or more 
networks together to form an internet. Additional detail can be found in (Burg et 
al .1984; Hinden et al. 1983; Israel and Weissberger, 1987; Poste 1980- 
Schneidewind 1983; S tailings 1987; and Weissberger and Israel 1987) 

Enormous controversy exists about the question of whether today's abundance 
of .network types is a temporary condition that will go away as soon as everyone 

of florid Tf^ ^ * " I**" ™ ^viuble/bui permanent feTtuf . 
of the world that is here to stay. We believe that a variety of different networks- 
will always be around for the following reasons. First of Si, the installed base of 

"° S J A SySt£mS ,S ^ ready ^ Iar S e ^ gr° win g rapidly. IBM is still selling 
new SNA systems Most UNIX shops run TCP/IP. LANs are rarely OSI This 
trend will continue for years because not all vendors perceive it in their interest for 
their customers to be able to easily migrate to another vendor's system 
m a H.° nC1, a V° mpUte ; S f d nerworks S eI cheaper, the place where decisions get 
made moves downward. Many companies have a policy to the effect that pur- 
chases costing over a million dollars have to be approved by top management bar- 
cnases costing over 100,000 dollars have to be approved by middle management 
out purchases under ,00.000 dollars can be made by department. heads withouTany 
higher approval. This can easily lead to the accounting department installing an 



\ 



r 



